The invention relates to a method of determining DB2 database objects lost as a result of a direct access storage device (DASD) failing or becoming otherwise unavailable. The method advantageously permits identification of DB2 objects to be recovered after the DASD volume has become unavailable--e.g., after failure has occurred or after the DASD volume has gone off-line. Moreover, the method advantageously permits identification of DB2 objects to be recovered without requiring pre-failure preparation processing--e.g., capturing volume table of contents (VTOC) listings. Additionally, the method advantageously permits identification of DB2 objects for recovery in close to "real time," i.e., 30 seconds to 10 minutes or so following DASD becoming unavailable, in contrast to prior time-consuming techniques. The identification of DB2 objects for recovery in close to "real time" is a significant benefit because important data is kept on the DASD. When DASD volume damage occurs, it is important to determine what data exists on the volume so that it can be recovered.
The general context of the operations associated with the invention is illustrated in FIG. 1, depicting a basic computer system 10. The system administrator or other end-user generally interacts with the computer system 10 through the input-output device commonly known as an end-user terminal 15. From the end-user terminal 15, the system administrator or other end-user may provide information to or receive information from the computer system's central processing unit (CPU) 20. The CPU 20 provides the "brains" of the computer system 10, generally having the abilities to fetch and execute instructions, arithmetically manipulate data, and control and communicate with the memory and input/output components, inter alia. A computer system 10 will also generally have one or more DASD volumes 25 for the storage of data. For any number of reasons, one or more DASD volumes 25 may become damaged or otherwise unavailable, creating the need for data recovery on the damaged or unavailable volumes.
In any information systems environment, the possibility of DASD failure is everpresent. When DASD failures occur, whether such failures are software-related, e.g., corrupted data, or hardware-related, e.g., physical damage to a disk platter, the result is loss of valuable business information for potentially long periods of time. Such "downtime" can cause great hardship for the affected enterprise. Conventional recovery techniques for DB2 objects have frequently been time-consuming and, quite often, less than satisfactory in their success rates. These deficiencies often arise in part from the difficulties of identifying DB2 objects to be recovered from a DASD volume that is no longer available.
Much if not most of the prior technology entails taking a "snapshot" of the DASD contents (i.e., an image, a hard copy, or a list of the VTOCs) prior to failure, i.e., while the DASD volume is still available. By definition, such a method requires that the DASD volume be accessible so that the volume table of contents can be read, and further that the DASD volume be at least comparatively undamaged.
A problem with this prior approach arises from the fact that, as a practical matter, the volume "snapshot" will reflect the state of the DASD volume at some time prior to the DASD failure. Consequently, the "snapshot" will not reflect recent changes to the volume that may have occurred because of user actions (e.g., additions, deletions, or modifications to the data) or automated system software control (e.g., storage optimization programs). This problem is particularly acute with more modern storage management technology, because data in volumes is often physically relocated on a real-time basis (e.g., by automated storage management programs).
In addition, "snapshot" analysis volume recovery is a complicated exercise. The "snapshot" generally will contain physical dataset names. These physical dataset names are mapped to DB2 object identifiers. "Snapshot" analysis volume recovery also involves identifying the DB2 subsystem(s) to which the objects to be recovered belong, because attempting to use a first DB2 subsystem to recover a DB2 dataset belonging to a second DB2 subsystem will generally be unsuccessful.
Physical reconstruction techniques have also been used to recover data from corrupted or damaged disks. This reconstruction technique generally entails, first, physically reading the magnetic ones and zeroes from the damaged disk and then attempting to reassemble these bits into meaningful information. The physical reconstruction approach is laborious, expensive, time-consuming, and of comparatively little value in time-sensitive situations.